1. Field of the Invention
The present invention relates to an improved data processing system and, in particular, to a method and apparatus for file system management.
2. Description of Related Art
Computer systems typically contain one or more massive direct access storage devices for persistently storing data, such as hard drives. While a storage device provides capacity for physical storage, related data is logically stored within these devices in the form of files. A file acts as a logical container for manipulating an amount of data as a larger, discrete unit. An operating system organizes files within a file system. The file system comprises logical associations between file system resources, e.g., files, volumes, directories, folders, the latter three of which act as containers for files; in addition, a file system resource may comprise an entire file system such that an entire remote file system becomes logically associated with a local file system. These logical associations are stored in data structures that are typically also stored within the same storage device.
Distributed data processing systems comprise multiple computational devices that communicate in some manner, e.g., on a common network. File systems have been enhanced to permit file sharing throughout a network, even though those files may be stored on storage devices that are controlled by disparate computational devices. In so doing, processes that are local to a particular computational device may access files that are physically stored on remote devices.
File system resources are shared in an explicit manner, thereby allowing a local file system to have some degree of control over which remote file system resources are available to its local processes. For example, a first file system may explicitly export a file system resource, e.g., a project directory, and a second file system may explicitly import the file system resource from the first file system. In this manner, a permission mechanism is established; a file system allows its file system resources to be accessed by another file system, and another file system allows its file system to access file system resources in a foreign file system.
In addition to permitting the sharing of a file system resource, a file system needs to manage a logical association between its local file system and the remote file system resource that is being accessed by its local processes. The sharing of file system resources may entail static, logical associations in persistent data structures, e.g., within system configuration files; it may also entail dynamically created, logical associations using data structures in volatile memory, or some combination of the two. The logical associations may be implemented using pathnames, namespaces, or other logical schemes.
In any case, the logical association provides a mechanism for a local file system to incorporate the remote file system resource into the data structures that the local file system uses to manage available file system resources. These logical associations between a local file system and a remote file system resource are created or destroyed through mount/unmount operations that are also used for local system resources; the creation of a logical association with a file system resource is termed a mount operation, and the destruction of the logical association is termed an unmount operation.
Some operating systems provide for the automatic mounting and unmounting of file system resources in an on-demand fashion or in an as-needed fashion; such file system resources are usually described as automount file system resources. An operating system employs an automount program, also referred to as an automount daemon or simply an automounter, to perform the operations that are necessary for mounting and unmounting automount file system resources, which are sometimes collectively referred to as automounting operations. When necessary, e.g., upon a request operation, a file system resource is automatically mounted on-demand to access the file system resource; file system resources are automatically unmounted due to inactivity or for other considerations, such as changes in file system configuration by a system administrator. While it may be convenient for an operating system to implement an automount feature for certain file system resources, the automount feature may be problematic in some instances.
For example, an operating system is typically organized such that a set of software modules at the kernel level within the operating system is responsible for implementing file-related operations; these software modules may be termed file subsystem modules. For expediency of description, any other kernel level modules other than the file subsystem modules can be grouped together, herein termed non-file-subsystem modules. When necessary, the non-file-subsystem modules may employ the file subsystem modules to access files or merely to obtain file-related information, i.e. metadata about files.
A problem may arise because a non-file-subsystem module may attempt to obtain file metadata about an unmounted automount file system resource without needing to access the automount file system resource. In order to obtain the file metadata information, a non-file-subsystem module may use certain functions that are implemented within file subsystem modules. In this situation, a file subsystem module would not need to mount the unmounted automount file system resource because the non-file-subsystem module does not need to access the automount file system resource. However, due to the nature of its code, a file subsystem module still attempts to mount the unmounted automount file system resource. Hence, even though the unmounted automount file system resource did not need to be mounted, the non-file-subsystem module can inadvertently cause an attempt to mount the unmounted automount file system resource. In some instances, the attempt to mount the unmounted automount file system resource may result in a severe error. In other instances, depending on the frequency of the actions by the non-file-subsystem module, its actions may have the unintended consequence of effectively maintaining an automount file system resource in a mounted state, thereby negating the benefits that are provided by the automount characteristic.
Although most operating systems implement one or more functions via a file subsystem module for determining whether a file system resource is an automount file system resource or for determining whether an automounted file system resource is mounted, these functions are typically only available to software modules at the application level, which are being supported by the kernel modules; in other words, these functions are not available to non-file-subsystem modules at the kernel level. Moreover, certain file metadata that is readily available to non-file-subsystem modules often does not contain any indications about whether a file system resource is an automount file system resource or whether an automounted file system resource is mounted.
Therefore, it would be advantageous to have a method and system for determining whether an automounted file system resource is mounted.